NAME¶

dhcp-eval - ISC DHCP conditional evaluation

DESCRIPTION¶

The Internet Systems Consortium DHCP client and server both provide the ability to perform conditional behavior depending on the contents of packets they receive. The syntax for specifying this conditional behaviour is documented here.

REFERENCE: CONDITIONAL BEHAVIOUR¶

Conditional behaviour is specified using the if statement and the else or elsif statements. A conditional statement can appear anywhere that a regular statement (e.g., an option statement) can appear, and can enclose one or more such statements. A typical conditional statement in a server might be:

if option dhcp-user-class = "accounting" {


  max-lease-time 17600;


  option domain-name "accounting.example.org";


  option domain-name-servers ns1.accounting.example.org, 
			     ns2.accounting.example.org;
} elsif option dhcp-user-class = "sales" {


  max-lease-time 17600;


  option domain-name "sales.example.org";


  option domain-name-servers ns1.sales.example.org, 
			     ns2.sales.example.org;
} elsif option dhcp-user-class = "engineering" {


  max-lease-time 17600;


  option domain-name "engineering.example.org";


  option domain-name-servers ns1.engineering.example.org, 
			     ns2.engineering.example.org;
} else {


  max-lease-time 600;


  option domain-name "misc.example.org";


  option domain-name-servers ns1.misc.example.org, 
			     ns2.misc.example.org;
}

On the client side, an example of conditional evaluation might be:

# example.org filters DNS at its firewall, so we have to use their DNS
# servers when we connect to their network.   If we are not at
# example.org, prefer our own DNS server.
if not option domain-name = "example.org" {


  prepend domain-name-servers 127.0.0.1;
}

The if statement and the elsif continuation statement both take boolean expressions as their arguments. That is, they take expressions that, when evaluated, produce a boolean result. If the expression evaluates to true, then the statements enclosed in braces following the if statement are executed, and all subsequent elsif and else clauses are skipped. Otherwise, each subsequent elsif clause's expression is checked, until an elsif clause is encountered whose test evaluates to true. If such a clause is found, the statements in braces following it are executed, and then any subsequent elsif and else clauses are skipped. If all the if and elsif clauses are checked but none of their expressions evaluate true, then if there is an else clause, the statements enclosed in braces following the else are evaluated. Boolean expressions that evaluate to null are treated as false in conditionals.

BOOLEAN EXPRESSIONS¶

The following is the current list of boolean expressions that are supported by the DHCP distribution.

data-expression-1 = data-expression-2

data-expression-1 ~= data-expression-2 data-expression-1 ~~ data-expression-2

boolean-expression-1 and boolean-expression-2

boolean-expression-1 or boolean-expression-2

not boolean-expression

exists option-name

DATA EXPRESSIONS¶

Several of the boolean expressions above depend on the results of evaluating data expressions. A list of these expressions is provided here.

substring (data-expr, offset, length)

suffix (data-expr, length)

lcase (data-expr)

ucase (data-expr)

option option-name

config-option option-name

hardware

packet (offset, length)

string

colon-separated hexadecimal list

concat (data-expr1, ..., data-exprN)

reverse (numeric-expr1, data-expr2)

leased-address

binary-to-ascii (numeric-expr1, numeric-expr2, data-expr1, data-expr2)

        concat (binary-to-ascii (10, 8, ".",


                                 reverse (1, leased-address)),


                ".in-addr.arpa.");

encode-int (numeric-expr, width)

pick-first-value (data-expr1 [ ... exprn ] )

host-decl-name

NUMERIC EXPRESSIONS¶

Numeric expressions are expressions that evaluate to an integer. In general, the maximum size of such an integer should not be assumed to be representable in fewer than 32 bits, but the precision of such integers may be more than 32 bits.

extract-int (data-expr, width)

lease-time

number

client-state

REFERENCE: ACTION EXPRESSIONS¶

log (priority, data-expr)

execute (command-path [, data-expr1, ... data-exprN]);

REFERENCE: DYNAMIC DNS UPDATES¶

The DHCP client and server have the ability to dynamically update the Domain Name System. Within the configuration files, you can define how you want the Domain Name System to be updated. These updates are RFC 2136 compliant so any DNS server supporting RFC 2136 should be able to accept updates from the DHCP server.

SECURITY¶

Support for TSIG and DNSSEC is not yet available. When you set your DNS server up to allow updates from the DHCP server or client, you may be exposing it to unauthorized updates. To avoid this, the best you can do right now is to use IP address-based packet filtering to prevent unauthorized hosts from submitting update requests. Obviously, there is currently no way to provide security for client updates - this will require TSIG or DNSSEC, neither of which is yet available in the DHCP distribution.

Dynamic DNS (DDNS) updates are performed by using the dns-update expression. The dns-update expression is a boolean expression that takes four parameters. If the update succeeds, the result is true. If it fails, the result is false. The four parameters that the are the resource record type (RR), the left hand side of the RR, the right hand side of the RR and the ttl that should be applied to the record. The simplest example of the use of the function can be found in the reference section of the dhcpd.conf file, where events are described. In this example several statements are being used to make the arguments to the dns-update.

In the example, the first argument to the first ate expression is a data expression that evaluates to the A RR type. The second argument is constructed by concatenating the DHCP host-name option with a text string containing the local domain, in this case "ssd.example.net". The third argument is constructed by converting the address the client has been assigned from a 32-bit number into an ascii string with each byte separated by a ".". The fourth argument, the TTL, specifies the amount of time remaining in the lease (note that this isn't really correct, since the DNS server will pass this TTL out whenever a request comes in, even if that is only a few seconds before the lease expires).

If the first dns-update statement succeeds, it is followed up with a second update to install a PTR RR. The installation of a PTR record is similar to installing an A RR except that the left hand side of the record is the leased address, reversed, with ".in-addr.arpa" concatenated. The right hand side is the fully qualified domain name of the client to which the address is being leased.

SEE ALSO¶

dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-options(5), dhcpd(8), dhclient(8), RFC2132, RFC2131.

AUTHOR¶

The Internet Systems Consortium DHCP Distribution was written by Ted Lemon under a contract with Vixie Labs. Funding for this project was provided through Internet Systems Consortium. Information about Internet Systems Consortium can be found at https://www.isc.org.